% ----------------------------------------------------------------------- %
% CAPITULO 4
% ----------------------------------------------------------------------- %

\chapter{Cenários}
\label{Cenarios}

\section{Cenários estudados}

Após os estudos bibliográficos sobre o NSIS e com base nos documentos lidos,
foram definidos alguns cenários de testes com fins de aprofundar o estudo dos
mecanismos integrantes do referido protocolo, bem como os seus modos de
operação.

Os seguintes cenários foram definidos para este trabalho:

\begin{enumerate}
\item Cenário 1: Sinalização por fluxo individual, com mensagem de reserva a
partir do emissor do fluxo;
\item Cenário 2: Sinalização por fluxo individual, com mensagem de reserva a
partir do receptor;
\item Cenário 3: Caso simples de sinalização com reserva real de recursos a
partir do emissor do fluxo;
\item Cenário 4: Caso detalhado do mecanismo de reserva e de gerência de
recursos usando várias reservas;
\item Cenário 5: Atualização de reserva face a mudanças de rota e o mecanismo de
\textit{soft-state};
\end{enumerate}

\section{Aspectos da Plataforma de Testes e da Operação do protocolo de
Goettingen}

\subsection{Plataforma de Testes}

Para a análise do protocolo foram utilizadas máquinas virtuais \textit{linux}
UML. Uma máquina virtual é um software que simula um computador, possibilitando a instalação de sistemas operacionais e programas. Estas
máquinas facilitam o controle das diversas entidades dos protocolos e evitam a
complexidade adicional no uso de diversas máquinas reais.

Um sistema de arquivos foi construído para o uso nas máquinas virtuais UML,
conforme descrito no apêndice \ref{Montar_vm}, onde foi instalada a versão 0.6.0
do
protocolo NSIS implementado na Universidade de Goettingen. Esta implementação
foi a escolhida, dada a forma estruturada do projeto e
das constantes atualizações a que vem sendo submetida.

Dentre os componentes do NSIS implementado pela universidade de Goettingen
cita-se o GIST (NTLP) e os protocolos de aplicação: NSIS-QoSD (Servidor
de gerenciamento de QoS) e o NAT/FW NSLP para testes e gerenciamento com
\textit{firewalls}. Além disto, um cliente do NSIS-QoS permite dar início as
sinalizações, segundo várias opções possíveis.

Em adição, nos cenários construídos foram utilizadas ferramentas para análise e
geração de tráfego, tais como o \textit{tcpdump} e o \textit{iperf}. No último
cenário, para auxiliar no roteamento, foi instalado e configurado o protocolo de
roteamento \textit{rip} através do software \textit{ZEBRA}\footnote{Software que implementa e gerencia protocolos e rotinas de roteamento}.

\subsection{Estrutura e Configuração do NSIS}
\label{cenario_conf}

Para o seu funcionamento, a implementação de Goettingen do NSIS requer que sua
camada de transporte (GIST) e os protocolos de sinalização (NSLPs) sejam
executados como processos independentes. Cada máquina, que se comporta como uma
entidade
NSIS, deve executar no mínimo o protocolo GIST e um protocolo NSLP.

O processo GIST possui uma API, baseada em soquetes, para acesso
as funcionalidades de transporte. Os demais protocolos NSLP acessam a API do
GIST para o transporte de suas mensagens. Cada protocolo NSLP é implementado
como
um processo. O protocolo QoS NSLP, foco de estudo deste trabalho, possui também
uma interface via soquetes, para permitir o acesso as suas funcionalidades por
parte de um programa cliente.

Dentro do diretório do NSIS,
encontra-se o diretório \textit{bin} com arquivos compilados do NSLP, entre eles
os arquivos \textit{nsis}, \textit{nsis-qos} e o \textit{nsis-ping}, além do
arquivo de configuração \textit{nsis.conf}.

O binário \textit{nsis} é um dos principais arquivos, que funciona como um
\textit{daemon} de
controle central: quando executado carrega as informações do arquivo de
configuração \textit{nsis.conf} e executa os demais componentes do protocolo. No
caso
deste estudo, os protocolos GIST e o protocolo QoS NSLP.

No arquivo de configuração \textit{nsis.conf} é possível habilitar os
\textit{daemons}
que se
deseja iniciar junto com a execução do nsis, além de configuração de IP, NAT/FW
e parâmetros da Função de Gerência de Recursos-RMF. Para os cenários citados, no
arquivo \textit{nsis.conf} de todas as entidades iniciadas, foi habilitado o
parâmetro
\textit{nslp.startQoS = yes}, que faz com que o \textit{daemon}
\textit{nsis-qosd} seja inicializado junto com o \textit{nsis}.

Um importante detalhe da configuração do arquivo \textit{nsis.conf} está na
configuração
de roteamento de rede através do parâmetro \textit{readRoutingTable} que permite
ao NSIS ler a tabela de roteamento do sistema  ou carregar as
configurações do arquivo, por interface.

A configuração utilizada na montagem do cenário, bem como  a configuração
resumida
do arquivo \textit{nsis.conf} de cada ponto está listada no respectivo ambiente
de teste.
Os detalhes destes arquivos pode ser vistos no apêndice \ref{cenario_anexo}.

\subsection{O cliente do protocolo QoS-NSLP}
\label{cap4_cliente_protocolo NSLP}

Para iniciar uma sinalização e efetuar uma reserva, o cliente do protocolo
QoS NSLP, \textit{nsis-qos}, é executado. Este cliente se comunica
com o \textit{daemon} do \textit{nsis-qos}, iniciado nos nós que terão passagem
do fluxo.

Para iniciar uma sinalização, associa-se a chamada do cliente \textit{nsis-qos}
com
alguns parâmetros na linha de comando, conforme o modelo de mensagem a ser
utilizado. Dentre os comandos, pode-se citar:
\begin{itemize}
 \item -res: Envia uma mensagem de reserva para uma sessão;
 \item -rt: Envia uma reserva como \textit{flag} T (\textit{Teardown Session})
para remover uma sessão;
 \item -q: Envia uma mensagem de prova, sem manter estado nos nós;
 \item -rir: Faz a sinalização de reserva a partir do nó de destino.
\end{itemize}

Utilizando o modo de análise do protocolo NSIS de Goettingen, foram feitas as
sinalizações e com base nas informações apresentadas pela depuração do protocolo
e descrição no texto deste trabalho foram feitos os devidos comentários.

%------------------------------------------------------------------------------%
\section{Cenário 1}
\label{cenario_ambiente1}
O modelo básico de sinalização do cliente NSIS QoS é a sinalização por fluxo
individual com reserva a partir do emissor do fluxo, ou seja, a sinalização de
reserva (mensagem RESERVE) é feita no mesmo sentido do envio do fluxo. Esta
sinalização também é chamada de sinalização no sentido sentido
\textit{downstream}.

Este cenário, conforme figura \ref{fig:cap4_cenario_ambiente1}, é composto dos
nós QNI, QNE e QNR,
sendo que o nó QNI, neste caso, é o emissor do fluxo de dados. Não foi realizada
a
configuração de reserva de recursos, ou seja, as mensagens de reserva serão
geradas normalmente, mas não existe função de gerenciamento de recursos nos nós.
Para isto, é feita a marcação no arquivo \textit{nsis.conf} na
opção qos.rmf com NullRMF: \verb|qos.rmf = NullRMF|. Esta restrição, permite
mostrar somente a sinalização.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.7]{figs/cenario.png}
 \caption{Cenário 1}
 \label{fig:cap4_cenario_ambiente1}
\end{figure}

Utilizou-se de um ambiente com as três unidade da rede, um nó QNE no meio, e
nas pontas os nós QNI e QNR, cujas informações de endereço segue abaixo. Os
detalhes da configuração podem ser verificados no anexo \ref{cenario_anexo}.
 
\begin{itemize}
 \item QNI
IP: eth0=192.168.19.11/24;
NSIS com NullRMF;
 \item QNE
IP: eth0=192.168.19.10/24
IP: eth1=192.168.24.10/24
NSIS com NullRMF;
 \item QNR
IP: eth0=192.168.24.11/24;
NSIS como NullRMF;
\end{itemize}


Considerando o \textit{daemon} nsis rodando em todos os nós, a partir do nó QNI,
se efetua a sinalização com o comando:

 \verb|./nsis-qos 192.168.24.11 -res|

Neste caso aplicou-se o IP do nó de destino e a variável \textit{-res} para
sinalização de reserva. Note que neste cenário não é efetuada reserva, e a
marcação de não efetuar reserva no nó QNE é respeitada.

Após a inicialização do comando, é gerado um fluxo de informações, obtidas
utilizando o modo depurador do protocolo. O modo depurador é configurado através
do arquivo \textit{nsis.conf}, no
parâmetro \textit{qos.debuglevel}, que recebe classificação de detalhes em ordem
crescente de 0 à 7. Na sequência é discutida a saída de depuração em cada nó.

\begin{enumerate}
\item O nó QNI envia um mensagem de sinalização para frente e marca o tempo que
aguarda por resposta (\textit{RespTimer started}   : 2s) e o tempo que ocorrerá
a mensagem de atualização de reserva (\textit{refresh}).

\begin{verbatim}
NullRMF: client connected
We are End Node (QNI)
SID: ffffffff ffffffff ffffffff ffffffff
QoSFsm::idle__rx_rmf_msg()
QoSFsm::inst__rx_rmf_msg()

QNI: outgoing msg -->
+ SII_Handle        : 
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 120 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0
RespTimer started   : 2s
RefrTimer started   : 30s
\end{verbatim}


\item O nó QNE recebe a mensagem de QNI e a encaminha para frente sem passar
para a camada de aplicação (função RMF), pois não recebeu pedido de recurso.
Aqui também permite que se verifique a marcação do tempo que ocorrerá a mensagem
de atualização de reserva e o tempo de armazenamento de estado, por se tratar de
um nó \textit{statefull} (\textit{StateTimer started}  : 100s). O campo
SII\_Handle indica o endereço da interface a partir da qual a mensagem saiu.

\begin{verbatim}
We are Entity  (QNE)

QNE: --> incoming msg
+ SII_Handle        : 192.168.19.11
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 120 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0

(...)

QNE: outgoing msg -->
+ SII_Handle        : 
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 120 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0
RefrTimer started   : 30s
StateTimer started  : 100s
\end{verbatim}
\item O nó QNR recebe a mensagem.
\begin{verbatim}
! We are End Node (QNR) !

QNR: --> incoming msg
+ SII_Handle        : 192.168.24.10
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 120 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0
\end{verbatim}

\end{enumerate}

De modo sequencial é possível ver o conjunto de mensagens e a sequência na
figura \ref{fig:cap4_cenario_reserve1}.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/cenario_reserve1.png}
 \caption{Sinalização de reserva}
 \label{fig:cap4_cenario_reserve1}
\end{figure}

Esta sinalização se mantém até que o \textit{State Timer}, tempo de
esgotamento (\textit{timeout}) que o estado
fique armazenado, termine ou até que o nó QNE receba uma mensagem com o
\textit{flag} T marcado. Este último serve para identificar a remoção do estado
(\textit{teardown}).

A partir do nó QNI, efetuou-se a solicitação de remoção de reserva com a
mensagem \verb|./nsis-qos 192.168.24.11 -rt|. Pode-se verificar o \textit{flag}
T marcado através da mensagem:

\begin{verbatim}
 QNI: outgoing msg -->
+ SII_Handle        : 
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 24 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 1:0:0:0:0:0
\end{verbatim}

Observe que outros meios de remoção do estado podem ocorrer, por exemplo, com a
queda de um dos pontos do domínio. A mensagem transporta um tempo de vida, que é
armazenado no nó e, caso dentro deste tempo não chegue uma atualização da
reserva, a reserva é derrubada. 

%------------------------------------------------------------------------------%
\section{Cenário 2}
\label{cenario_ambiente2}
O modelo anterior, com a reserva no sentido \textit{downstream} é um modelo
básico de sinalização, onde a sinalização é feita no sentido do fluxo. Contudo,
o NSIS é capaz de gerar a reserva de fluxo a partir do nó destino, sentido
\textit{upstream}, para isto é feita a
chamada do \textit{nsis-qos} associada ao comando \textit{-rir}.

Neste caso, utilizou-se o mesmo ambiente do cenário anterior, rearranjado
conforme a figura \ref{fig:cap4_cenario_ambiente2} e  com informações de
endereço
indicadas abaixo. Para visualizar detalhes da configuração, o leitor pode ser
referenciar ao apêndice \ref{cenario_anexo}. 

\begin{itemize}
 \item QNR
IP: eth0=192.168.19.11/24;
NSIS com NullRMF;
 \item QNE
IP: eth0=192.168.19.10/24
IP: eth1=192.168.24.10/24
NSIS com NullRMF;
 \item QNI
IP: eth0=192.168.24.11/24;
NSIS como NullRMF;
\end{itemize}

Considerando o NSIS rodando em todos os nós, a partir do nó QNR, efetua-se a
solicitação de verificação de recursos com o comando:

 \verb|./nsis-qos 192.168.24.11 -rir|

Onde \textit{-rir} é o flag para a reserva a partir do receptor.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/cenario2.png}
 \caption{Cenário 2}
 \label{fig:cap4_cenario_ambiente2}
\end{figure}

Com o comando \textit{-rir} (\textit{Receiver Initiated Reservation}) ativo o
nsis gera sinalização de reserva pelo lado oposto ao que o fluxo é recebido.
Para fazer a reserva a partir do receptor do fluxo (\textit{Receiver Initiated
Reservation}), o QNR envia uma mensagem QUERY, que pode conter uma especificação
de fluxo. A mensagem QUERY pode ser usado para coletar informações ao longo do
caminho. Neste caso, será feita uma consulta de estado no caminho, para isto a
mensagem deve ter o Flag R ativo e depois iniciado a reserva.

Analisando o tráfego a partir do nó QNE, que é o nó que fará a reserva, é
possível verificar o fluxo de mensagens:

\begin{verbatim}
We are End Node (QNR)

QNR: outgoing msg -->
+ SII_Handle        : 
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 68 bytes
+ QoS Message Type  : QUERY
+ T:R:B:A:P:S-Flag  : 0:1:0:0:0:0
\end{verbatim}

O nó QNE recebe a sinalização de QUERY advinda do nó QNR (srcAddr=192.168.19.11)
para o nó QNI (destAddr=192.168.24.11). A função \verb|idle__rx_query()| marca o
recebimento de uma query pelo GIST e a passagem para a máquina de estado, que
estará esperando por uma resposta. Neste caso, o NSIS aciona a função
\verb|wr__rx_rmf_msg()| onde uma mensagem de reserva tenha sido acionada,
conforme a mensagem de saída do nó QNE.

\begin{verbatim}
We are Entity  (QNE)

QNE: --> incoming msg
+ SII_Handle        : 192.168.19.11
+ srcAddr           : 192.168.24.11
+ destAddr          : 192.168.19.11
+ direction         : UPSTREAM
+ msg length        : 68 bytes
+ QoS Message Type  : QUERY
+ T:R:B:A:P:S-Flag  : 0:1:0:0:0:0

triggerEvent        : ST_IDLE::EV_RX_QUERY

QoSFsm::idle__rx_query()
StateTimer started  : 30s
transition to       : ST_WR
QoSFsm::wr__rx_rmf_msg()
\end{verbatim}

Neste momento, o nó QNE recebe uma mensagem de RESERVE advinda do nó QNI,
contudo, repare na condição das informações do cabeçalho:

\begin{itemize}
\item SII\_Handle: 192.168.24.11: Observa-se abaixo que realmente a fonte (src)
é
advinda do IP do nó QNI, contudo, o cabeçalho SII\_Handle vem marcado pelo
originador da sinalização. SII é na, tradução para o português, a informação que
identifica a fonte (\textit{Source Identification Information});
 \item srcAddr: 192.168.24.11: Originador da mensagem;
 \item destAddr: 192.168.19.11: Destino da mensagem;
\end{itemize}

Com isto, a mensagem de reserva é enviada para o nó QNE, que efetuará
a reserva, a marcação é realizada de maneira correta, no sentido do fluxo.

\begin{verbatim}
QNE: --> incoming msg
+ SII_Handle        : 192.168.24.11
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 80 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0
\end{verbatim}

O fluxo de mensagens é mostrado na Fig.\ref{fig:cap4_cenario_reserve_2}
\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/cenario_reserve2.png}
 \caption{Fluxo de Sinalização de reserva com query}
 \label{fig:cap4_cenario_reserve_2}
\end{figure}

%------------------------------------------------------------------------------%
\section{Cenário 3}
\label{cenario_ambiente3}
Nos cenários anteriores, foi mostrado somente a sinalização, sem nenhuma
alocação
de recurso para o fluxo, isto porque o nó QNE estava marcado para não efetuar a
reserva. Contudo, o NSIS permite, junto a sinalização, o envio da entidade QSPEC
com a especificação de fluxo. Esta especificação será interpretada pela função
de gerenciamento de recurso. Será realizada então uma sinalização  por fluxo
individual com reserva a partir do emissor do fluxo, ou seja, a sinalização é
feita no mesmo sentido do envio do fluxo.

Este cenário, conforme figura \ref{fig:cap_cenario3}, é composto dos nós QNI,
QNE e QNR, com
configuração de reserva de recursos para o nó central QNE. Para isto, altera-se
no \textit{nsis.conf} o parâmetro \textit{qos.rmf} para \textit{SimpleRMF}
(\textit{qos.rmf = SimpleRMF}), conforme
cenário apresentado:

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.6]{figs/cenario3.png}
 \caption{Cenário com reserva de recurso}
 \label{fig:cap_cenario3}
\end{figure}

Para este cenários, utilizou-se de um ambiente semelhante aos anteriores, com
somente um nó QNE no \textit{core} e este efetua a reserva, conforme abaixo.
Caso queira
visualizar detalhes da configuração, verifique o apêndice \ref{cenario_anexo}.
\begin{itemize}
 \item QNI
IP: eth0=192.168.19.11/24;
NSIS como NullRMF;
Software iperf como cliente para fluxo priorizado;
 \item QNE
IP: eth0=192.168.19.10/24
IP: eth1=192.168.24.10/24
NSIS como SimpleRMF, fazendo reserva;
 \item QNR
IP: eth0=192.168.24.11/24;
NSIS como NullRMF;
Software iperf como servidor do fluxo priorizado;
\end{itemize}

\subsection{Iniciando a função de RMF do NSIS}

A função de reserva de recursos (RMF) do NSIS se utiliza de ferramentas do
próprio \textit{linux}, como o
\textit{iptables} e o \textit{tc}. O \textit{iptables} é uma ferramenta de filtro de pacotes
baseado
em regras pré determinadas. O \textit{tc (traffic control)} é uma ferramenta de
controle de tráfego e pode ser utilizada para gerenciamento de QoS em redes. O
NSIS utiliza destas ferramentas como comandos, implementados na aplicação,
requerendo que os programas \textit{iptables} e \textit{tc} estejam instalados.

O \textit{tc} implementa o \ac{QDISC} como algoritmo de classificação de tráfego na saída do
fluxo. o QDISC é capaz de gerenciar o fluxo de
uma interface, seja na entrada ou na saída do fluxo, criando associações de
regras hierárquicas para a interface. O QDISC tem uma raiz (\textit{root}) que é
associada a uma interface.

No QDISC adicionam-se classes onde são implementadas as políticas de tratamento
do fluxo. Dentro de uma classe podem haver outras classes além de outro qdisc,
com outra disciplina de fluxo. Portanto, uma classe pode ter um QDISC como pai
(\textit{parent}) ou uma outra classe. O QDISC precisa de um classificador para
determinar qual a classe que precisa enviar um pacote. Isto é feito utilizando o
\textit{filter}.

Durante a inicialização do NSIS no nó QNE com a marcação para
\textit{SimpleRMF},
verifica-se o \textit{tc} rodando, inicialmente apaga as classes que poderiam ter sido
criadas e em seguida monta a estrutura de priorização:
\begin{verbatim}
(TC) Running "tc qdisc delete dev eth1 root handle 1:"
(IpTables) Running "iptables -t mangle -F PREROUTING"
(IpTables) Running "ip6tables -t mangle -F PREROUTING"
(TC) Running "tc qdisc add dev eth1 root handle 1: htb default 2"
(TC) Running "tc class add dev eth1 parent 1: classid 1:1 htb rate
 100kbit ceil 100kbit burst 100kbit"
(TC) Running "tc class add dev eth1 parent 1:1 classid 1:2 htb rate
 100kbit burst 100kbit ceil 0 mpu 0"
(TC) Running "tc qdisc add dev eth1 parent 1:2 handle 2: sfq perturb 10"
\end{verbatim}

A estrutura criada pode ser visualizada conforme figura
\ref{fig:cap4_tc_start_nsis}:
\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/tc_start_nsis.png}
 \caption{Criação da estrutura de controle de tráfego}
 \label{fig:cap4_tc_start_nsis}
\end{figure}

Observa-se que é aplicado uma classe com taxa (\textit{rate}) de 100kbit
limitando
o fluxo não priorizado, o que pode ser visto com o iperf:

\begin{verbatim}
(none):~# iperf -s -i 0
WARNING: interval too small, increasing from 0.00 to 0.5 seconds.
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.24.11 port 5001 connected with 192.168.19.11 port 36655
[  4]  0.0- 0.5 sec  9.90 KBytes    162 Kbits/sec
[  4]  0.5- 1.0 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  1.0- 1.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  1.5- 2.0 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  2.0- 2.5 sec  6.66 KBytes    86 Kbits/sec
[  4]  2.5- 3.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  3.0- 3.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  3.5- 4.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  4.0- 4.5 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  4.5- 5.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  5.0- 5.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  5.5- 6.0 sec  5.66 KBytes  92.7 Kbits/sec
\end{verbatim}

\subsection{Efetuando a reserva para um fluxo}

Considerando o nsis rodando em todos os nós, a partir do nó QNI, se efetua a
solicitação de reserva de fluxo com o comando:

 \verb|./nsis-qos 192.168.24.11 -res -bw 50 -p 6 -dpt 9876|

Onde \textit{-res} de reserva, \textit{-bw} para especificar a quantidade de
banda desejada em bytes por segundo, \textit{-p 6} para utilizar protocolo TCP e
\textit{-dpt 9876} para especificar uma porta de destino para a reserva.

Neste momento é gerado um fluxo de informações, coletadas do modo \textit{debug} do
protocolo, que podem ser melhores descritas a partir do nó QNI.

\begin{enumerate}
\item O Nó QNI envia uma mensagem de reserva (RESERVE);
\item Após recebe uma mensagem NOTIFY confirmando que existe recurso: \textit{RR
supported}.
\item A partir da confirmação o nó QNI envia uma mensagem de resposta (RESPONSE)
para informar o envio do fluxo.
\end{enumerate}

De modo sequencial pode-se ver o conjunto de mensagens e a sequência na figura
\ref{fig:cap4_cenario_reserve3}

\begin{itemize}
 \item QNI sinaliza para QNR;
 \item QNE intermedia e verifica informações;
 \item QNE aloca recursos;
\begin{verbatim}
Reserving ...
(TC) Running "tc class add dev eth1 parent 1:1 classid 1:6 htb rate
 500bps burst 500 ceil 500bps mpu 64"
HTB: quantum of class 10006 is small. Consider r2q change.
(TC) Running "tc qdisc add dev eth1 parent 1:6 handle 6: sfq perturb 10"
(TC) Running "tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32
 match ip
src 192.168.19.11/32 match ip dst 192.168.24.11/32 match ip protocol 6 0xff
match ip dport 9876 0xffff  flowid 1:6"
\end{verbatim}
 \item As atualizações de máquina de estado são encaminhadas entre os nós
\verb|+++ QSPEC object    : QoS Available|
\verb|+++ Object type     : Tmod1, length:4|
\verb|+++ QSPEC object    : Minimum QoS|
\item QNR responde a sinalização
\item QNE respode a QNI e reserva recursos.
\end{itemize}

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/cenario_reserve1.png}
 \caption{Sinalização de reserva}
 \label{fig:cap4_cenario_reserve3}
\end{figure}

\subsection{Análise da Saída do Depurador}

Após a reserva de recursos, o estado da garantia de recursos se mantém por
sinalização de estado, \textit{soft-state}, gerada de tempos em tempos. Esta mensagem tem
o intuito apenas de manter o estado e carrega informações de fonte e destino, ID
da reserva e tipo de mensagem. O evento é gerado pelo nó QNI, que ao chegar ao
nó QNE chama a função \verb|inst__rx_reserve()|, que compara o identificador da
reserva com os atuais, se o valor for o mesmo que o armazenado, a reserva é
atualizada. Um modelo pode ser visto abaixo:

\begin{verbatim}
----------------------------------------
QoSFsm: refresh_timeout()

triggerEvent        : ST_INST::EV_TIMEOUT_REFRESH

QoSFsm::inst__timeout_refresh()

QNE: outgoing msg -->
+ SII_Handle        : 
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 16 bytes
+ QoS Message Type  : RESERVE
+ Object Type       : RSN
++ RSN              : 1
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0
RefrTimer restarted : 30s

transition to       : ST_INST

SID: ffffffff ffffffff ffffffff ffffffff
fsm                 : 0x80f4c28

QNE: --> incoming msg
+ SII_Handle        : 192.168.19.11
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 16 bytes
+ QoS Message Type  : RESERVE
+ Object Type       : RSN
++ RSN              : 1
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0

triggerEvent        : ST_INST::EV_RX_RESERVE

QoSFsm::inst__rx_reserve()
StateTimer restarted: 100s

transition to       : ST_INST

\end{verbatim}

Para se remover uma reserva, basta utilizar o parâmetro \textit{-t}, de derrubar
(do inglês \textit{teardown}). Este modelo ativa o \textit{flag} T que associa
um
tempo para a
reserva, se associado sem tempo determinado, remove a reserva. O procedimento de
remoção de reserva também pode ser feito manualmente, como no exemplo:

\verb|./nsis-qos 192.168.24.11 -rt -bw 50 -p 6 -dpt 9876|

Para o caso desta sinalização utilizou-se os mesmo parâmetros da reserva,
contudo, o \textit{flag} T foi enviado com o parâmetro \textit{-rt}.

Outros meios são a queda de um dos nós de um domínio. Cada reserva tem associada
um tempo de
vida, que é o tempo que ficará o estado armazenado em um roteador. Caso dentro
deste tempo não chegue atualização da
reserva, esta é derrubada. 

\begin{verbatim}
SID: ffffffff ffffffff ffffffff ffffffff
fsm                 : 0x80f4c28

QNE: --> incoming msg
+ SII_Handle        : 192.168.19.11
+ srcAddr           : 192.168.21.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 24 bytes
+ QoS Message Type  : RESERVE
+ T:R:B:A:P:S-Flag  : 1:0:0:0:0:0

triggerEvent        : ST_INST::EV_RX_RESERVE

QoSFsm::inst__rx_reserve()
StateTimer started  : 30s

transition to       : ST_WR
\end{verbatim}

Novamente a mensagem é recebida, é feita a chamada função
\verb|inst__rx_reserve()|, da máquina de estado, verifica o marcador
\textit{T-FLAG}
setado (campo T:R:B:A:P:S-Flag:), e libera a reserva.

\begin{verbatim}
Refresh Timer stoped
Releasing reservation ...
(TC) Running "tc filter delete dev eth1 protocol ip parent 1:0 prio 1 u32
 match ip src 192.168.19.11/32 match ip dst 192.168.24.11/32 match ip
 protocol 6 0xff match ip dport 9876 0xffff  flowid 1:6"
(TC) Running "tc class delete dev eth1 parent 1:1 classid 1:6"
QoSFsm::wr__rx_rmf_msg()
\end{verbatim}

%------------------------------------------------------------------------------%
\section{Cenário 4}
\label{cenario_ambiente4}

No cenário anterior podê-se verificar o mecanismo de reserva de recurso RMF
atuando. Foi efetuada sinalização com reserva e o mecanismo de gerência de
recursos efetuou esta reserva. Contudo foi feita apenas uma reserva para um
fluxo individual.

Neste cenário o RMF efetua a gerência de recurso para várias requisições que
entram e solicitam alocação. Para melhor visualizar as reservas é feita a
redução do tamanho de
alocação de banda para 100kbit e efetua-se então as várias reservas, para em
seguida observar comportamento.

Para este cenários, utilizou-se de um ambiente semelhante aos anteriores, com
somente um nó QNE no \textit{meio} sendo que somente este efetua a reserva.
Entretanto, será utilizado dois nós adjacentes além dos utilizados, pra fluxo
não priorizado conforme indicado na Fig.\ref{fig:cap4_cenario4}. Para maiores
detalhes da configuração, verificar o ítem \ref{cenario_anexo}:

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/cenario4.png}
 \caption{Cenário com reserva de recurso}
 \label{fig:cap4_cenario4}
\end{figure}

A configuração básica do cenário é, portanto:

\begin{itemize}
 \item QNI
IP: eth0=192.168.19.11/24;
NSIS como NullRMF;
Software iperf como cliente para fluxo priorizado;
 \item QNI
IP: eth0=192.168.19.12/24;
NSIS como NullRMF;
Software iperf como cliente para fluxo não priorizado;
 \item QNE
IP: eth0=192.168.19.10/24
IP: eth1=192.168.24.10/24
NSIS como SimpleRMF, fazendo reserva;
 \item QNR
IP: eth0=192.168.24.11/24;
NSIS como NullRMF;
Software iperf como servidor do fluxo priorizado;
 \item QNR
IP: eth0=192.168.24.12/24;
NSIS como NullRMF;
Software iperf como servidor do fluxo não priorizado;
\end{itemize}

\subsection{Iniciando a função de RMF do NSIS}

Na inicialização do nsis, é aplicado uma classe com taxa \textit{rate} de
100kbit limitando o fluxo não priorizado, o que pode ser visto com o iperf:

\begin{verbatim}
(none):~# iperf -s -i 0
WARNING: interval too small, increasing from 0.00 to 0.5 seconds.
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.24.11 port 5001 connected with 192.168.19.11 port 35855
[  4]  0.0- 0.5 sec  9.90 KBytes    162 Kbits/sec
[  4]  0.5- 1.0 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  1.0- 1.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  1.5- 2.0 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  2.0- 2.5 sec  7.07 KBytes    116 Kbits/sec
[  4]  2.5- 3.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  3.0- 3.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  3.5- 4.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  4.0- 4.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  4.5- 5.0 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  5.0- 5.5 sec  5.66 KBytes  92.7 Kbits/sec
[  4]  5.5- 6.0 sec  5.66 KBytes  92.7 Kbits/sec
\end{verbatim}

A cada reserva, será criada uma nova disciplina QDISC, que tratará o fluxo
informado. O RMF tratará o fluxo de acordo com as informações passadas pela
sinalização e fará os cálculos necessários para a agregação desta reserva.

Neste cenário será solicitado 4 reservas de fluxo, de 50Kbps, 40kbps, 10kpbs e
10kbps respectivamente. Contudo, deve-se atentar para um detalhe, o link foi
limitado a 100kbps, ou seja, a última reserva, de 10kps não poderá ser feita, a
menos que uma das anteriores seja retirada, devido a saturação do link.

\subsection{Efetuando a reserva para um fluxo}

Efetua-se então as reservas a partir do QNI:
\begin{itemize}
 \item Para 50kbps


\verb|./nsis-qos 192.168.24.11 -res -bw 50000 -p 6 -sid 76 -dpt 9876|

 \subitem E verifica-se a reserva no nó QNE:
\begin{verbatim}
 Reserving ...
(TC) Running "tc class add dev eth1 parent 1:1 classid 1:6 htb rate
 48kbps burst 50000 ceil 48kbps mpu 64"
(TC) Running "tc qdisc add dev eth1 parent 1:6 handle 6: sfq perturb 10"
(TC) Running "tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32
 match ip
src 192.168.19.11/32 match ip dst 192.168.24.11/32 match ip protocol 6 0xff
match ip dport 9876 0xffff  flowid 1:6"
\end{verbatim}

 \item Em seguida, é feita a reserva de Para 40kbps


\verb|./nsis-qos 192.168.24.11 -res -bw 40000 -p 6 -sid 77 -dpt 9877|


 \subitem E verifica-se a reserva no nó QNE:
\begin{verbatim}
Reserving ...
(TC) Running "tc class add dev eth1 parent 1:1 classid 1:7 htb rate
 39kbps burst 40000 ceil 39kbps mpu 64"
(TC) Running "tc qdisc add dev eth1 parent 1:7 handle 7: sfq perturb 10"
(TC) Running "tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32
 match ip
src 192.168.19.11/32 match ip dst 192.168.24.11/32 match ip protocol 6 0xff
match ip dport 9877 0xffff  flowid 1:7"
\end{verbatim}

 \item Em seguida, a reserva de Para 10kbps


\verb|./nsis-qos 192.168.24.11 -res -bw 10000 -p 6 -sid 78 -dpt 9878|


 \subitem E verifica-se a reserva no nó QNE:
\begin{verbatim}
Reserving ...
(TC) Running "tc class add dev eth1 parent 1:1 classid 1:8 htb rate
 10000bps burst 10000 ceil 10000bps mpu 64"
(TC) Running "tc qdisc add dev eth1 parent 1:8 handle 8: sfq perturb 10"
(TC) Running "tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32
 match ip
src 192.168.19.11/32 match ip dst 192.168.24.11/32 match ip protocol 6 0xff
match ip dport 9877 0xffff  flowid 1:8"
\end{verbatim}

\item No entanto, conforme esperado, a última reserva não foi efetuada, pois não
havia banda suficiente para alocação.


\verb|./nsis-qos 192.168.24.11 -res -bw 10000 -p 6 -sid 79 -dpt 9879|


\end{itemize}

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.7]{figs/tc_reserv_nsis.png}
 \caption{Classes de fluxo do controle de tráfego}
 \label{fig:cap4_tc_reserv_nsis}
\end{figure}

Com as alocações de banda efetuadas, cada fluxo priorizado tem a admissão de
banda garantida sobre fluxos não priorizados. Isto pode ser visto utilizando o
iperf, para isto foi efetuada a reserva de 50kbps e a de 40 kbps, restando
10kbps para o fluxo não priorizado. Em paralelo, é inserido tráfego na
rede, conforme a reserva para averiguar a garantia de banda.

\begin{itemize}
 \item Taxa de tráfego para o fluxo priorizado:
\begin{verbatim}
WARNING: interval too small, increasing from 0.00 to 0.5 seconds.

------------------------------------------------------------
Server listening on TCP port 9877
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.24.11 port 9877 connected with 192.168.19.11 port 40751
[  4]  0.0- 0.5 sec  4.24 KBytes  69.5 Kbits/sec
[  4]  0.5- 1.0 sec  2.83 KBytes  46.3 Kbits/sec
[  4]  1.0- 1.5 sec  2.83 KBytes  46.3 Kbits/sec
[  4]  1.5- 2.0 sec  1.41 KBytes  23.2 Kbits/sec
[  4]  2.0- 2.5 sec  1.41 KBytes  23.2 Kbits/sec
[  4]  2.5- 3.0 sec  2.83 KBytes  46.3 Kbits/sec
 \end{verbatim}

 \item Taxa de tráfego para o fluxo não priorizado:
\begin{verbatim}
 (none):/NSIS/nsis-0.6.0/bin# iperf -s -i 0
WARNING: interval too small, increasing from 0.00 to 0.5 seconds.
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.24.12 port 5001 connected with 192.168.19.12 port 40718
[  4]  0.0- 0.5 sec  4.24 KBytes  46.3 Kbits/sec
[  4]  0.5- 1.0 sec  4.24 KBytes  0.00 Kbits/sec
[  4]  1.0- 1.5 sec  2.83 KBytes  0.00 Kbits/sec
[  4]  1.5- 2.0 sec  2.83 KBytes  0.00 Kbits/sec
[  4]  2.0- 2.5 sec  1.41 KBytes  23.2 Kbits/sec
[  4]  2.5- 3.0 sec  1.41 KBytes  23.2 Kbits/sec
[  4]  3.0- 3.5 sec  2.83 KBytes  0.00 Kbits/sec
[  4]  3.5- 4.0 sec  1.41 KBytes  0.00 Kbits/sec
\end{verbatim}
\end{itemize}

%------------------------------------------------------------------------------%
\section{Cenário 5}
\label{cenario_ambiente5}

Neste cenário, observa-se um dos modelos do NSIS que o diferencia de modelos de
sinalização, como o RSVP, por exemplo. A capacidade de reler a tabela de
roteamento e refazer a reserva em caso de mudança de rota. Na mensagem de
atualização de estado, verifica-se que o NSIS analisa se a reserva já existia, e
caso nao exista, esta é efetuada.

Como o NSIS é um protocolo em desenvolvimento, este modelo ainda não foi
implementado em sua totalidade, contudo, foram efetuadas as devidas análises.

No cenário utilizado deu-se preferência para que cada nó do cenário efetue
uma tarefa, sendo que as bordas fazem e recebem a sinalização, o nó central faz
a reserva deixando outros dois nós exclusivos ao roteamento.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.4]{figs/cenario5.png}
 \caption{Sinalização com mudanca de rota}
 \label{fig:cap4_cenario_change_route}
\end{figure}

No cenário montado o \textit{nsis} foi inicializado em todos os nós, e uma reserva foi
feita de uma ponta a outra para o fluxo ser transmitido pela rede
192.168.21.0/24 e 192.168.22.0/24. Nos quatro nós do núcleo, está rodando
algorítimos de roteamento, de modo que derrubando uma interface, a rota se refaz
automaticamente.

Feita a sinalização, a reserva foi efetuada entre os nós do domínio. Em seguida
as rotas do roteador ROT1 onde o fluxo estava passando foram removidas. Como o
NSIS, através o \textit{soft-state}, mantém mensagens de atualização da
reserva, ao enviar a mensagem de \textit{refresh}, a mudança é detectada.

Com este cenário, o comportamento esperado do NSIS, seria efetuar a reserva no
novo caminho, contudo, em nossos testes, não foi possível efetuar a reserva no
novo cenário.

Feita uma análise, diagnosticou-se que durante a inicialização do
\textit{daemon} nsis, a configuração de roteamento é carregada pelo nsis para o
GIST, tanto se explícita no arquivo \textit{nsis.conf}, como se lendo a tabela de
roteamento. E a tabela de rotas do GIST não estava sendo atualizada.

A importância do protocolo de sinalização conhecer a tabela de roteamento se dá
em conhecer o caminho e o destino do fluxo e justamente prover a capacidade
de detectar a mudança por comparação de rota.

Contudo, neste mesmo cenário foi possível verificar o protocolo
\textit{soft-state}
com mais detalhes. Uma vez que a rota não pode ser atualizada, o NSIS deve
sinalizar a partir do nó adjacente a mudança para os nós seguintes para a
remoção do status da sessão que foi aberta para reserva.

Conforme descrito no ítem \ref{cap3_reroteamento}, a sinalização é feita após o
tempo de atualização de mensagems expirar, em seguida, sinaliza-se até encontrar
o novo caminho, caso não se encontre, a reserva é removida. Conforme pode ser
visto a partir do nós adjacente a antiga reserva:

\begin{itemize}
 \item O nó detecta a mudança:
\textit{handleMessageStatus} (\textit{GIST was unable to establish routing state with the peer}).

 \item O nó adjacente sinaliza para trás a informação de nova rota;
\begin{verbatim}
QNE: --> incoming msg
+ SII_Handle        : 192.168.20.10
+ srcAddr           : 192.168.19.11
+ destAddr          : 192.168.24.11
+ direction         : DOWNSTREAM
+ msg length        : 16 bytes
+ QoS Message Type  : RESERVE
+ Object Type       : RSN
++ RSN              : 1
++ EpochID          : 0x49ae3885
+ T:R:B:A:P:S-Flag  : 0:0:0:0:0:0

triggerEvent        : ST_INST::EV_RX_RESERVE

QoSFsm::inst__rx_reserve()
StateTimer restarted: 100s
\end{verbatim}

\begin{itemize}
 \item As mensagens reservas são derrubadas.
\end{itemize}

\end{itemize}
